Skip to content

Conversation

nicktindall
Copy link
Contributor

@nicktindall nicktindall commented Sep 19, 2025

This approach keeps track of the best NOT_PREFERRED moves seen when iterating through looking for NOs.

If we get to the end of the moveShards loop and we can still make moves, we will pick one of the NOT_PREFERRED moves to make.

There is no prioritisation of NO moves in this approach, anything with a decider returning NO will be moved as soon as we encounter it in the node-interleaved iterator.

if (canRemain.type() == Type.NOT_PREFERRED && bestNonPreferredShardsByNode.containsKey(shardRouting.currentNodeId())) {
int compare = comparatorCache.computeIfAbsent(
shardRouting.currentNodeId(),
nodeId -> new ShardMovementPriorityComparator(allocation, allocation.routingNodes().node(nodeId))
Copy link
Contributor Author

@nicktindall nicktindall Sep 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By caching these, we are sorting all shards by the values calculated when the comparator was first created. It's likely that the threshold and maximum will move as shards are moved, but given that we don't move too much in each iteration, I think it's fine to accept the potential for slight differences.

@nicktindall nicktindall added >non-issue :Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) labels Sep 22, 2025
Comment on lines +848 to +849
// Return after a single move so that the change can be simulated before further moves are made.
return true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to check if (completeEarlyOnShardAssignmentChange) here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opted not to because it's happening after all the NO moves and this is new behaviour, we know that we rely on the simulation being updated for these movements to make sense so I don't think we should ever attempt more than one.

Copy link
Contributor

@DiannaHohensee DiannaHohensee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code changes look good to me, I left a few more suggestions.

I still need to look at the testing, but I've got an appointment, so publishing the comments I have.

Copy link
Contributor

@DiannaHohensee DiannaHohensee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to have IT testing with the DesiredBalanceShardsAllocator. This test could be updated: would need to give it a range of shard write loads, and then check that a specific shard was moved.

I'm totally fine with that testing being a follow up, however you prefer.

Left a lot of comments, but I think they're simple, so approving now. Let me know if you want me to take another look.

@nicktindall
Copy link
Contributor Author

It would be good to have IT testing with the DesiredBalanceShardsAllocator. This test could be updated: would need to give it [a range of shard write loads]

Thanks for the reviews! I've added the write loads to the test you mentioned and assert that the "best" shard is moved in 4170af3

@nicktindall
Copy link
Contributor Author

Buildkite benchmark this with many-shards-quantitative please

@elasticmachine
Copy link
Collaborator

elasticmachine commented Oct 6, 2025

💚 Build Succeeded

This build ran two many-shards-quantitative benchmarks to evaluate performance impact of this PR.

History

Copy link
Contributor

@DiannaHohensee DiannaHohensee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the IT testing. Looks good 👍

@nicktindall nicktindall enabled auto-merge (squash) October 6, 2025 23:00
@nicktindall nicktindall merged commit c19d4d7 into elastic:main Oct 7, 2025
34 checks passed
@nicktindall nicktindall deleted the ES-12739_select_hot_shard_to_move_off_data_node_v2 branch October 7, 2025 00:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) >non-issue Team:Distributed Coordination Meta label for Distributed Coordination team v9.3.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants